Recording a Positive Experience with TDD and Pair Programming

Posted on Sunday, 16 Feb 2025

Why We Did Pair Programming

A colleague needed to add a new feature to a module I had recently worked on. After struggling with it for a week, he managed to implement the feature. However, during QA, we discovered that the new feature wasn’t functioning as expected. My colleague reached out to me for help, and we decided to fix the module together through pair programming.

Utilizing TDD

We opened a Slack huddle, and I shared my screen. As we discussed where to start, I suggested that we begin by writing test cases. We first wrote a test case to capture the issue at hand and then proceeded to fix the errors one by one based on the logs. Fortunately, our project already had well-structured unit tests, and I could easily get where and how to add test cases for the new feature.

Edge Cases

The goal was to ensure that when an “A-type” product was being shipped, it would follow a unique flow compared to other product types. My colleague had already written test cases for scenarios where a package contained only A-type products and where there were no A-type products at all. However, he had not accounted for mixed packages containing both A-type and other product types. We wrote a test case for this mixed-package scenario.

The test case itself was fewer than 20 lines of code. We temporarily commented out other test cases and ran the new one, as expected, it failed. We then dug into the error message. I asked my colleague about his reasoning behind the existing logic, and through this discussion, I realized that he had misunderstood certain aspects of my original implementation. We went through multiple iterations of modifying the code and running the test.

Aligning Our Thoughts

By revisiting the problematic logic together, I was able to recall the thought process I had when I originally wrote the code. My colleague, in turn, gained a clearer understanding of the original intent behind the logic. The test cases provided a clear structure for our discussion, making it easier to identify what needed to be fixed.

Finally, the error was gone. After a brief review of our changes, we uncommented the other test cases and ran the entire test suite. We got an OK result with no errors.

Conclusion

Our patch passed QA without any major issues, allowing us to redeploy quickly. Looking back, choosing TDD wasn’t a deliberate decision—it was a necessity. The edge case was clear, and the most natural way to approach it was to add a test and use it to debug the issue. Both my colleague and I found the process satisfying, and we shared this experience during our team retrospective that week.

Tags: devnote , pairprogramming , tdd